1. Field of the Invention
The present invention relates to computer systems, and deals more particularly with methods, systems, and computer program products for resolving context conflicts (for example, a person's electronic calendar shows that he has a meeting scheduled in a particular location, but a badge reader or tracking device indicates that he is elsewhere), and programmatically updating the context source, invalidating the source (at least temporarily), or notifying the supplier of context information.
2. Description of the Related Art
The term “context service”, as used herein, refers to an automated service that provides information about user context. Context services are known in the art. Examples of context services include a system referred to as “Owl” in “Issues for Context Services for Pervasive Computing”, M. R. Ebling et al., in Proceedings of the Workshop on Middleware for Mobile Computing 2001, Heidelberg, Germany (November 2001), and the Context Toolkit from Georgia Institute of Technology. Refer to http:/www.cs.arizona.edu/mmc/Program.html and http://www.cc.gatech.edu/fce/contexttoolkit for more information on these context services.
A context service may receive context information from a variety of sources, including electronic calendars, location sensors, and other sensors such as badge readers and motion detectors. The context service then provides the context information to one or more applications, allowing those applications to be “context aware”. Examples of context-aware applications include the following: (1) a notification system that sends notifications to a pager or other device; (2) a location-based service that provides location-specific information (such as traffic data) to a user, depending on the user's context; and (3) a travel-time calculator that uses a person's current location to determine when the person will arrive at another location.
FIG. 1 shows a high-level view of a context service of the prior art. The source of the context information is represented at the left with examples such as an electronic calendar system 100, a cellular phone 110, and a badge reader 120.
The electronic calendar system 100 may be a product such as Lotus Notes®, Microsoft Outlook® 2000, or Microsoft Exchange, or it may be an advanced calendar system such as that disclosed in the related patents. (“Lotus Notes” is a registered trademark of Lotus Development Corporation and “Outlook” is a registered trademark of Microsoft Corporation.) A calendar system provides context information such as a calendar owner's scheduled events, and optimally the location of meetings and other events, preferred means of contact during certain events, and so forth.
A cell phone 110 may be used to provide context information about its user such as the user's physical location, and the cell phone may also provide device information such as its telephone number or serial number.
A badge reader 120 can be used to provide information about the identification of people who have passed their badge through the reader, as well as the time and location at which this occurred. “Smart badges”, on the other hand, function as transmitters that provide continuous location information without requiring explicit action at a badge reader.
Other sources of context information 130 might include a motion detector in an office building. For example, an organization might place motion detectors in offices or conference rooms in order to automatically turn off the lights when no movement has been detected for a configurable time interval. Executing application programs may be capable of determining a level of awareness about their users (e.g., whether the user is logged in, logged off, inactive, and so forth) and may be another source of context information.
Each context source typically has a context receiver, shown generally at 140 of FIG. 1. A context receiver receives, analyzes, and interprets input from the context source, and then makes this information available to applications via the application programming interface (“API”) 150. An example of context interpretation is the translation of geographical coordinates into a street address or a building and office number. An example of analysis is the reduction of frequently-transmitted location data into more meaningful events. That is, most applications don't need or want to know if a person moves within his office or a meeting room, but would like to be informed if the person moves to another room or leaves the building.
The granularity of context information provided to an application 160, 170 may be determined in a variety of ways, according to the prior art. For example, a configurable number of events might be sampled during a configurable time interval. Values of these configurable parameters may vary depending on factors such as a user's location. Thus, an application might receive less granular movement information for a person who is driving down the highway and more granular information for that same person if he is moving within a building.
Context sources can be categorized into two basic types, updateable and fixed, as shown at 200 and 210 in FIG. 2. The updateable context sources are sources such as electronic calendars where the context can be changed at the source to update or correct the context information. (That is, if a user's calendar data provides incorrect context information about the user, then the calendar can be modified.) Fixed context sources are devices such as cell phones with embedded global positioning system (“GPS”) receivers that are not designed to be adjusted at the source. As shown in FIG. 2, a plurality of context sources (represented by the basic types 200 and 210) may be used in a context-aware system, each typically sending its context information to a context receiver, shown generally at 220.
This context information is gathered for and provided to context-aware applications 160, 170. The applications can use the context directly or may use the services of a mediator (shown in FIG. 2 at 230), which can receive multiple sources of context information and provide consolidated and more accurate context information to the applications. For example, the same or related context information may be sensed by multiple redundant sensors. By comparing the different sources, the mediator can provide more precise context information to the applications. For example, if there are three redundant sensors, a voting procedure might be used to select one of them. Or, algorithmic comparisons might be used to reject the source with the largest variation among them.
Electronic calendars often contain a wealth of information about their owners. For example, an individual may use an electronic calendar to maintain information about his work schedule, his meetings and other appointments, his vacation and business travel plans (including when he will be away, which flights or other transportation he will use, where he can be reached while away, who he may visit while away, etc.), phone calls that need to be made at particular times, and so forth.
Electronic calendars may be accessed by people and/or by applications. Calendar data can be used to automate tasks and to inform others about things such as whether the calendar owner is currently available, or is out of the office on business, and so forth. For example, the related invention titled “Calendar Events and Calendar-Driven Application Technique” (U.S. Pat. No. 6,988,128) uses calendar data to automate voice mail greetings, among other things. It does this by analyzing calendar data, including a person's scheduled working hours and other scheduled events. The related invention titled “Calendar-Enhanced Awareness for Instant Messaging Systems and Electronic Status Boards” (U.S. Pat. No. 7,284,002) discloses techniques whereby calendar data is used as input to instant messaging (“IM”) systems and electronic status boards. With the increasing use of calendar data, such as disclosed in these related inventions, it becomes more important to keep calendar data up-to-date and accurate.
Occasionally, a person's electronic calendar may not accurately represent his current status. For example, if Lisa is scheduled to be in a meeting from 3 p.m. to 5 p.m. on Friday, but she becomes ill at lunch time and goes home for the rest of the day, her calendar will likely reflect that she should be in her office until 3 p.m., and then in the conference room where the meeting is scheduled for the next two hours. In days past, it was the responsibility of a human administrative assistant or secretary to tend to employees' calendars, taking care of these types of schedule updates. Very few employees have this luxury today, however, and instead are responsible for maintaining their own schedules using electronic calendars. When a calendar user has to manually update her electronic calendar for every variation in her working hours and the meetings and other events which occupy those working hours, it is likely that some updates will not be made. As a result, accesses to the user's calendar data will provide incorrect information about her availability. Accesses may be made by individuals and/or by applications. For example, suppose Ellen is attempting to schedule a last-minute department meeting with all of her co-workers, including Lisa, for Friday afternoon between 2 p.m. and 3 p.m., and accesses their electronic calendars to see whether they will be in the office. Based on Lisa's inaccurate calendar information, Ellen will mistakenly believe that Lisa can attend.
With reference to the related invention titled “Calendar Events and Calendar-Driven Application Technique” (U.S. Pat. No. 6,988,128), if an automated voice mail system according to this related invention takes an incoming call to a calendar user's phone number and generates a message for the caller based on that user's inaccurate calendar data, the caller will be incorrectly informed as to the user's availability. In some cases, this is merely a nuisance. On the other hand, if someone needs to locate the calendar user for an important business matter or for a personal emergency, the incorrect information can have significant consequences.
In general, when an electronic calendar user's actual schedule does not conform to the information that has been provided to the calendar system, individuals looking at the calendar can be misled and applications that rely on calendar data for input cannot function optimally. Similarly, when applications other than electronic calendar systems are using context information that is incorrect, those applications cannot perform optimally. Accordingly, what is needed are improvements that enable context information such as calendar data to more accurately reflect a user's actual status.